High Level Overview of Change

New Definition

A holder's LPToken is now considered "frozen" if at least one of the two assets in the associated liquidity pool is regularly frozen.

Background

Prior to this amendment, a blacklisted account that owns frozen LPTokens could still transfer them through mechanisms such as Payments, Checks, Offers, or NFTs. This loophole allowed the recipient of these LPTokens to redeem or withdraw the underlying assets of the pool, bypassing the restrictions that should have applied to the blacklisted account. This behavior undermines the freezing mechanism's integrity and creates inconsistencies in asset control.

Note: this amendment only works with the existing regular freeze, and has no correlation with deep-freeze

Example

1. Alice deposits XRP and USD into an AMM pool.
2. The USD issuer freezes Alice's USD trustline.
3. Alice transfers her LPToken to Bob (although Alice cannot transfer USD directly, she can still transfer the LPToken).
4. Bob redeems USD using the received LPToken, effectively bypassing the freezing restrictions imposed on Alice.

Amendment changes

This amendment ensures that frozen LPTokens cannot be transferred. Below are the changes to specific transaction types:

Payments

• A blacklisted account can no longer send frozen LPTokens through direct payment.
• Offers attempting to sell frozen LPTokens can no longer be consumed on the DEX.

OfferCreate

• Accounts are prohibited from creating offers that attempt to sell frozen LPTokens.

CheckCash

• Cashing a check fails if it attempts to cash a frozen LPToken from the sender.

NFTokenCreateOffer

• Buyers are prohibited from creating buy offers involving frozen LPTokens.

NFTokenAcceptOffer

• Buyers cannot accept a sell offer if the offer requires the use of frozen LPTokens as payment.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Performance (increase or change in throughput and/or latency)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)